IN THE SPECIFICATION : 

Please amend the Specification as follows. 

Please replace paragraph [0004] with the following amended paragraph: 
[0004] Wireless personal area networks are cost-effective and use low power 
wireless devices that have a typical range of about ten meters. The best-known example 
of wireless personal area network technology is Bluetooth BLUETOOTH ^ which uses 
the 2.4 GHz ISM band. It provides a peak air link speed of one Mbps, and power 
consumption low enough for use in personal, portable electronics such as PDAs and 
mobile phones. Wireless local area networks generally operate at higher peak speeds of 
about 2 to 100 Mbps and have a longer range, which requires greater power consumption. 

Please replace paragraph [0024] with the following amended paragraph: 
[0024] The above communication environment typically includes a mobile 
network and one or more short-range wireless networks. The mobile network may be 
based on the UMTS (Universal Mobile Telecommunication System) or on the GSM 
(Global System of Mobile communications) network architecture, for example. The 
short-range wireless network(s) may in turn be based on various technologies, such as 
Wireless Local Area Network (WLAN), Sfaeteet hBLUETOOTH or Ultra Wide Band 
(UWB) technology. The access domain may thus include base stations 130 (or node B 



elements) of the mobile network and access points 140 of the short-range wireless 
systems. The backbone domain includes a plurality of service providers 150. 

Please replace paragraph [0032] with the following amended paragraph: 
[0032] When the user of the terminal starts the applicatio n (step 204) , the 
terminal may perform a quality negotiation with the user (step 205). In this step, the 
quality class set is presented to the user and the user is queried to select a quality class. 
However, as discussed below, the quality class set is not necessarily presented to the user 
as such, but the terminal may map the quality classes of the set to "quality modes" which 
may be presented in a simplified language to the user. When the user selects one of the 
quality modes, the terminal maps the selected quality mode to a set of quality classes 
(step 206), which is here termed a QoS set, since it is normally not the same set as the 
quality class set of the application instance, but rather a subset of the quality class set 
since the choice of the user typically limits the number of possible classes. The terminal 
then performs a QoS handshake with a communicating terminal (step 207) to agree on at 
least one quality class common to the terminals to be used for the session and possibly 
also on the radio resources to be utilized (step 208) . If the quality classes do not indicate 
the corresponding radio technology, the terminals may also agree on the radio technology 
in the handshake. Otherwise the terminals may select the radio resources based on the 
agreed quality class(es) after the handshake. 
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Please replace paragraph [0036] with the following amended paragraph: 
[0036] FIG. 3 illustrates an example of the quality negotiation performed with 
the user. As mentioned above, the quality class set of the application is not necessarily 
presented to the user as such, but the terminal may map the classes to "quality modes" to 
improve the user-friendliness of the process. For example, the terminal may display 
quality modes such as "low performance and low battery consumption", "medium 
performance and medium battery consumption", and "high performance and high battery 
consumption" to the user and ask the user to select one of these modes. The terminal may 
thus map the quality classes of the application instance to quality modes of the above 
kind (step 300) and present the quality modes to the user (step 301). When the user 
selects a mode (step 302), the terminal maps the selected mode back to a QoS set (step 
303). The QoS set is typically a subset of the quality class set, the subset being defined by 
the selection of the user. The QoS set, which indicates one or more quality classes, is sent 
to the opposite terminal during the handshake (cf. step 207). 

Please replace paragraph [0038] with the following amended paragraph: 
[0038] FIG. 4 illustrates the architecture of a multimode terminal 100 according 
to one embodiment of the invention. It is assumed here that the terminal comprises an 
interface 400 to a mobile network, such as a GSM or an UMTS network, and a plurality 
of short-range radio interfaces, such as a WLAN interface 401, a 
Bluetooth BLUETOOTH interface 402, and a UWB interface 403. It is further assumed 
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here that the terminal comprises a radio frequency identification (RFID) interface, which 
is used for the above-described QoS handshake in proximity communication. The RFID 
interface may form a RFID tag reader, which may also be capable of acting as a RFID 
tag. 

Please replace paragraph [0045] with the following amended paragraph: 
[0045] The QoS handshake may also be performed through another short-range 
radio interface than the RFID interface, such as the Bluetooth BLUETOOTH interface. It 
is also possible that the QoS set is first read through the RFID interface and then the 
subsequent negotiation is performed through another interface. 

Please replace paragraph [0048] with the following amended paragraph: 
[0048] FIG. 5 illustrates an example of the operation of a terminal when receiving 
a QoS set from an external terminal wishing to join an on-going session between a group 
of two or more terminals. The wish may be detected as an external terminal reads the 
quality class set through the RFID interface, for example. When the QoS set is received 
from an external terminal (step 500), the terminal examines, whether the received QoS 
set is acceptable for the group (step 501), either as such or after reselection of the 
common quality class(es). If this is not so, joining is denied (step 502). If reselection is 
needed (step 503) , a quality negotiation is performed within the group and at least one 
new quality class and radio resources are selected for the group now including a new 
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terminal (steps 504 to 506). The reselection may result in a change in the radio 
technology used. 

Please replace paragraph [0050] with the following amended paragraph: 
[0050] FIG. 6 is a schematic presentation of one embodiment of an ad-hoc 
terminal according to the invention. The core of the terminal is a control unit 600, which 
is connected to various interfaces of the terminal. Generally, the interfaces of the terminal 
may be divided into two classes: interfaces for ad-hoc networks and interfaces for the 
network infrastructure. However, depending on the type of the ad-hoc terminal, it may be 
provided with ad-hoc interfaces only. The ad-hoc interfaces include one or more 
interfaces 610, 611, each offering the functionality needed to accomplish connectivity to 
an ad-hoc network of a particular type. As shown above, the terminal may further include 
one short-range radio interface 650, such as a RFID interface, which is used for the QoS 
selection process only. Several ad-hoc interfaces are necessary, at least whenever the 
terminal acts as a trunk node that serves ad-hoc networks based on different technologies. 
For example, one ad-hoc network served may be based on WLAN technology, while 
another one may be based on Bluotooth BLUETOOTH or UWB technology. 

Please replace paragraph [0051] with the following amended paragraph: 
[0051] The interfaces to the supporting infrastructure also include one or more 
interfaces 620, 621, each offering the functionality needed to accomplish connectivity to 
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a system (i.e. network infrastructure) of a particular type. For example, interface 444-620 
may offer connectivity to a GSM or UMTS network, while interface 44 ^621 offers 
connectivity to a WLAN network. 
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